home *** CD-ROM | disk | FTP | other *** search
/ The 640 MEG Shareware Studio 2 / The 640 Meg Shareware Studio CD-ROM Volume II (Data Express)(1993).ISO / info / vl5_190.zip / VL5-190.TXT
Internet Message Format  |  1992-12-01  |  32KB

  1. From lehigh.edu!virus-l Mon Nov 30 22:10:29 1992
  2. Date: Mon, 30 Nov 1992 15:46:02 -0500
  3. Message-Id: <9211301938.AA03847@barnabas.cert.org>
  4. Comment: Virus Discussion List
  5. Originator: virus-l@lehigh.edu
  6. Errors-To: krvw@cert.org
  7. Reply-To: <virus-l@lehigh.edu>
  8. Sender: virus-l@lehigh.edu
  9. Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
  10. From: "Kenneth R. van Wyk" <krvw@cert.org>
  11. To:   Multiple recipients of list <virus-l@lehigh.edu>
  12. Subject: VIRUS-L Digest V5 #190
  13. Status: R
  14.  
  15. VIRUS-L Digest   Monday, 30 Nov 1992    Volume 5 : Issue 190
  16.  
  17. Today's Topics:
  18.  
  19. Re: MODE.COM vs. DAME virus (PC)
  20. Re: HELP!! Ever hear of this virus before? (PC)
  21. Stoned Virus Loss (PC)
  22. Re: SCAN 95b doesn't find MtE in EXE files (PC)
  23. Re: SCAN 95b doesn't find MtE in EXE files (PC)
  24. Re: F-Prot Bug (?) fixed. Thanks! (PC)
  25. Re: VSIGN - question. (PC)
  26. Re: FDISK /MBR and FORM Virus (PC)
  27. Re: Bug in F-Prot2.06a (PC)
  28. Key press cleaner and recover (PC)
  29. Re: FDISK /MBR and FORM Virus (PC)
  30. Re: FDISK /MBR and FORM Virus (PC)
  31. Re: Click, Click, Click when I typed help format (PC)
  32. Re: Atari ST Viruses! & Questions on the "Batman" virus (Atari ST)
  33. Re: Mr. Slade's listings
  34. Evaluations of AV products (was: Mr. Slade's listings)
  35. Re: What is this "AV BBS list" nonsense? (general)
  36. Re: Mr. Slade's Listings
  37. re: CHRISTMA Data (CVP)
  38. Re: Mr. Slade's listings
  39.  
  40. VIRUS-L is a moderated, digested mail forum for discussing computer
  41. virus issues; comp.virus is a non-digested Usenet counterpart.
  42. Discussions are not limited to any one hardware/software platform -
  43. diversity is welcomed.  Contributions should be relevant, concise,
  44. polite, etc.  (The complete set of posting guidelines is available by
  45. FTP on cert.sei.cmu.edu or upon request.) Please sign submissions with
  46. your real name.  Send contributions to VIRUS-L@LEHIGH.EDU.
  47. Information on accessing anti-virus, documentation, and back-issue
  48. archives is distributed periodically on the list.  A FAQ (Frequently
  49. Asked Questions) document and all of the back-issues are available by
  50. anonymous FTP on cert.org (192.88.209.5).  Administrative mail
  51. (comments, suggestions, and so forth) should be sent to me at:
  52. <krvw@CERT.ORG>.
  53.  
  54.    Ken van Wyk
  55.  
  56. ----------------------------------------------------------------------
  57.  
  58. Date:    25 Nov 92 03:37:50 +0000
  59. From:    tck@bend.ucsd.edu (Kevin Marcus)
  60. Subject: Re: MODE.COM vs. DAME virus (PC)
  61.  
  62. woody@knapper.cactus.org (Woody Baker) writes:
  63. >We got a positive indication of the DAME virus on an old compaq dos disk.
  64. >mode.com is the only file identified.  It appears to have a length of aboutt
  65. >4k or so.  Dame was not found in memory, just on this disk.  Dumping the
  66. >file with psa Dump utility, shows a batch of strings at offset c60..
  67. >"The compaq...version 3.1" etc.  The file ends at offset 1050.  This is
  68. >from a copy.  That is, I copied the mode.com off to dame.vir on the hard
  69. >disk.  The info I see on Dame indicates that it is a stealth virus, and
  70. >adds about 3K to the file.  It appends it's self to the end of the file.
  71. >I have a hard time believeing that mode was less than 1K long, when offset
  72. >c60 has an obvious string that belongs there.  I presume that this is a
  73. >false positive?  Any comments?
  74.  
  75. DAME, as reported by scan, means, "Dark Avenger Mutation Engine."
  76. This is a tool that is used in virus construction, rather than a virus
  77. itself.  Try using a different scanner.
  78.  
  79. ------------------------------
  80.  
  81. Date:    25 Nov 92 03:42:21 +0000
  82. From:    tck@bend.ucsd.edu (Kevin Marcus)
  83. Subject: Re: HELP!! Ever hear of this virus before? (PC)
  84.  
  85. The lock up is a bug in the demo.  The authors knew it, and they put an
  86. option in the command line to run it one demo at a time.  I believe the
  87. format would be "unreal p1" through "unreal p9".  Try this.
  88.  
  89. >>I have the dos version of 'ls'.  Whenever I run 'dir' on the system disk,
  90. >everything appears normal. However when I run 'ls' on the system disk,
  91. >two bizarre files show up at the end of the listing. They have the form
  92. >like:   chnsyz27asu   (not exactly that)  but no '.' and they change
  93. >every time I do the 'ls'.
  94. >
  95. >Now what the $#!@& did I catch?????????    Anybody ever run into this???
  96.  
  97. This sounds like it might be a bug in "ls", also.  You might want to
  98. run chkdsk and look for some funny allocation errors, and see if there
  99. are soem hidden files that maybe your version of ls is picking up that
  100. a regular "dir" command would not.
  101.  
  102. ------------------------------
  103.  
  104. Date:    Wed, 25 Nov 92 03:15:27 -0500
  105. From:    errol@edstar.gse.ucsb.edu (Errol Simpson)
  106. Subject: Stoned Virus Loss (PC)
  107.  
  108.   I have a 486 pc 33 mhz MSDOS 5.0 with a 212 meg IDE harddrive.
  109.   The "Your PC is now Stoned" message was followed by complete los of
  110. the drive Not even the Western Digital low level format utility nor
  111. Diskmanager, Fdisk, Spinrite2.20, or Speedstor will access the drive
  112. although all correctly read the Bios specifications for drive type.
  113. The drive is not recognised as being present or as being accessible or
  114. as responding in any fashion.
  115.  I have tried to get fixmbr24.zip via anon ftp from
  116. esel.cosy.sbg.ac.at where my archie server shows it to be available
  117. but I get access denied to the antivirus directory after successful
  118. ftp anon login.
  119.    I don't think the drive is recoverable but anyone with any
  120. ideas please contact me at the edstar address below. I would like to
  121. get fixmbr for future disasters. I have lost about 6 months research
  122. work ( the tape backup fails to restore correctly) so any help would
  123. be gratefully received.
  124.  
  125. *************************************************************
  126. * ERROL SIMPSON                *Phone                       *
  127. * Research / Analysis          *(805) 893 4700 / 4762       *
  128. * Systemwide Education Abroad  *Fax (805) 893 2583          *
  129. * University of California     *BITNET                      *
  130. * Hollister Research Building  *ea05mail@ucsbvm.bitnet      *
  131. * 6550 Hollister Avenue        *INTERNET                    *
  132. * Goleta CA 93117              *6500erro@ucsbuxa.ucsb.edu   *
  133. * USA                          *errol@edstar.gse.ucsb.edu   *
  134. *************************************************************
  135.  
  136. ------------------------------
  137.  
  138. Date:    25 Nov 92 09:30:31 +0000
  139. From:    frisk@complex.is (Fridrik Skulason)
  140. Subject: Re: SCAN 95b doesn't find MtE in EXE files (PC)
  141.  
  142. Stefano_Turci@f108.n391.z9.virnet.bad.se (Stefano Turci) writes:
  143.  
  144. >May be I didn't explain it well, I didn't compress it with LZEXE, I
  145. >just took a COM file with a length of XXX bytes and converted it to a
  146. >EXE file with a length of XXX+32 bytes, simply adding a 32 bytes long
  147. >header.
  148.  
  149. OK - maybe I should not have said "A new level of encryption", but rather that
  150. you just disguised the MtE.  I am sorry, but as I said there is no reasonable
  151. way to handle all possible ways to disguise or encrypt viruses. Even if a
  152. program detects a virus normally, it is always possible to hide it somehow.
  153.  
  154. >The fact is that F-prot misses all the converted infected files if the
  155. >length of the body is greater than 5120 bytes.
  156.  
  157. I'm not surprised.  I had not even realized it detected any of the converted
  158. files at all.  F-PROT finds MtE-infected files.  Period.  That's all I
  159. promise.  I make no promises regarding virus droppers - they may or may not
  160. be found - depending what method was used to create them.
  161.  
  162. However, one very strange thing....according to your information, my
  163. scanner reports the files it finds to be infected with "MtE (?)", but not
  164. "MtE" - now...this usually means that it finds a MtE signature string -
  165. taken from the decrypted virus engine, instead of using an algorithmic
  166. approach.  That implies that the converted files contain a non-encrypted MtE
  167. engine.  This also explains why some programs find it - as they probably just
  168. scanned either the entire file, or a buffer larger than I use.
  169.  
  170. If the files had been encrypted before they were modified, I am fairly sure
  171. that at least some of the programs that found the MtE would have missed it.
  172.  
  173. However, my final comment remains that there is nothing particularly
  174. remarkable about this, nor is there anything I intend to do.  I don't intend
  175. to chase all possible ways of writing virus droppers - I just intend to write
  176. (one of) the best program to find and disinfect virus-infected files.
  177.  
  178. - -frisk
  179.  
  180. ------------------------------
  181.  
  182. Date:    25 Nov 92 09:46:03 +0000
  183. From:    frisk@complex.is (Fridrik Skulason)
  184. Subject: Re: SCAN 95b doesn't find MtE in EXE files (PC)
  185.  
  186. Stefano_Turci@f108.n391.z9.virnet.bad.se (Stefano Turci) writes:
  187.  
  188. >If a copy of the virus remains cause your a-v detector could't find it
  189. >you'll probably be infected again.
  190.  
  191. >That's why I think a-v programs should be able to detect also these
  192. >forms.
  193.  
  194. You are of course free to think so - but the fact remains that this is
  195. impossible.  An AV program might be able to find most virus droppers
  196. most of the time, but it will not find all of them all of the time.
  197. This is not simply because it is practically impossible - it is a
  198. theoretical impossibility - the proof of that seems to be just a
  199. simple variation of the proof of the unsolvability of the halting
  200. problem.
  201.  
  202. >If you can't detect a copy of that virus, then it's possible to find
  203. >files like those on the Bulletin Boards all around the world.
  204.  
  205. When such files appear and are found to be virus-infected, we can
  206. easily add detection of each particular method of virus-dropper
  207. generation method.
  208.  
  209. HOWEVER.  AS I HAVE SAID BEFORE, AND WILL CONTINUE TO SAY - IT IS
  210. SIMPLY NOT POSSIBLE TO WRITE A PROGRAM THAT WILL DETECT ALL VIRUS
  211. DROPPERS - EVEN IF IT JUST DROPS KNOWN VIRUSES.
  212.  
  213. - -frisk
  214.  
  215. ------------------------------
  216.  
  217. Date:    25 Nov 92 09:50:13 +0000
  218. From:    frisk@complex.is (Fridrik Skulason)
  219. Subject: Re: F-Prot Bug (?) fixed. Thanks! (PC)
  220.  
  221. VXC15931@VAX1.Mankato.MSUS.EDU writes:
  222.  
  223. >I think I've found the problem on the F-Prot 2.06a I have reported
  224. >earlier.  Frisk told me that it could be a memory problem.  So it is.
  225.  
  226. Yes - I admit that 2.06a is a bit memory-intensive.  I am working on a
  227. permanent solution to the problem, but that will not be until version
  228. 2.07 (after Christmas, I guess).  I will probably release version
  229. 2.05b in the meantime, where I have reduced the memory requirements
  230. slightly. I have to make a few other changes/improvements first,
  231. though.
  232.  
  233. - -frisk
  234.  
  235. ------------------------------
  236.  
  237. Date:    25 Nov 92 09:52:50 +0000
  238. From:    frisk@complex.is (Fridrik Skulason)
  239. Subject: Re: VSIGN - question. (PC)
  240.  
  241. eres@trboun.bitnet (M.HAKKI ERES) writes:
  242.  
  243. >hi all.
  244.  
  245. >i've detected vsign virus with f-prot 2.05 in a 386 machine, but it
  246. >can not disinfect it.
  247.  
  248. Disinfection of this virus was added in 2.06.
  249.  
  250. - -frisk
  251.  
  252. ------------------------------
  253.  
  254. Date:    25 Nov 92 09:58:31 +0000
  255. From:    frisk@complex.is (Fridrik Skulason)
  256. Subject: Re: FDISK /MBR and FORM Virus (PC)
  257.  
  258. gscobie@castle.edinburgh.ac.uk (G J Scobie) writes:
  259.  
  260. >Hi there,
  261.  
  262. >Thanks for all the info regarding FDISK /MBR.  However, I attempted to
  263. >disinfect a PS/2 Model 55 with the FORM virus using a coldboot from my
  264. >DOS 5.0 disk created for such a purpose, ran FDISK /MBR and then ran
  265. >F-PROT 2.05 and it still reported FORM as being present in the boot
  266. >sector.
  267.  
  268. Which is exactly what should be expected - as FDISK /MBR just restores
  269. the MBR, which FORM does not infect at all.  In fact F-PROT reported
  270. the boot sector to be infected, not the MBR.
  271.  
  272. >  Using SYS.COM, then running F-PROT again showed the disk to
  273. >be clean.
  274.  
  275. SYS restores the DOS boot sector, where the virus resides.  To get rid
  276. of FORM, either use SYS (not FDISK) or use F-PROT 2.06.  2.05 could
  277. remove it from diskettes, but would sometimes refuse to disinfect hard
  278. disks - that was fixed in 2.06.
  279.  
  280. - -frisk
  281.  
  282. ------------------------------
  283.  
  284. Date:    25 Nov 92 10:01:36 +0000
  285. From:    frisk@complex.is (Fridrik Skulason)
  286. Subject: Re: Bug in F-Prot2.06a (PC)
  287.  
  288. voorhis@aecom.yu.edu (Adrienne Voorhis) writes:
  289.  
  290. >     I have also found that F-Prot2.06a will conk out on me when I try
  291. >to look at virus information.  The circumstances are somewhat complex,
  292. >so it's hardly a pure example, but other people seem to be having a
  293. >problem recreating it, so here it is:
  294.  
  295. I have found and fixed the problem.  It turned out to be a simple
  296. memory allocation problem, which only appears if you look at multiple
  297. virus descriptions.....sorry folks.  Expect an updated version soon.
  298.  
  299. - -frisk
  300.  
  301. ------------------------------
  302.  
  303. Date:    25 Nov 92 14:19:58 +0000
  304. From:    beshir@csd4.csd.uwm.edu (Abubaker Ali Ibrahim)
  305. Subject: Key press cleaner and recover (PC)
  306.  
  307. Is there any virus clean, for the keypress and to recover
  308. files(programs). any soluation please send e-mail
  309.  
  310. ibrhaim
  311. beshir@csd4.csd.uwm.edu
  312.  
  313. ------------------------------
  314.  
  315. Date:    Wed, 25 Nov 92 10:26:56 -0500
  316. From:    "David M. Chess" <chess@watson.ibm.com>
  317. Subject: Re: FDISK /MBR and FORM Virus (PC)
  318.  
  319. >From:    G J Scobie <gscobie@castle.edinburgh.ac.uk>
  320. >
  321. >Hi there,
  322. >
  323. >Thanks for all the info regarding FDISK /MBR.  However, I attempted to
  324. >disinfect a PS/2 Model 55 with the FORM virus using a coldboot from my
  325. >DOS 5.0 disk created for such a purpose, ran FDISK /MBR...
  326.  
  327. The FORM infects the operating system boot record, not the master boot
  328. record.  FDISK /MBR will be completely ineffective against the FORM.
  329. If it's a DOS partition that's infected, the SYS command should
  330. generally work, but there are lots of versions of SYS out there, and I
  331. have heard (although I have not verified) that some of them will leave
  332. the existing boot record alone if it "looks OK".  Also, if you try to
  333. SYS a hard disk after booting with one version of DOS, but the hard
  334. disk previously had an earlier version of DOS on it, there may not be
  335. room for the system files (it's always best to SYS with the same
  336. version that was there before infection).  Best is probably to use an
  337. anti-virus program that knows how to specifically repair FORM-infected
  338. partitions.
  339.  
  340. (NOTE: if an OS/2 machine with BootManager installed is booted from a
  341. FORM-infected diskette, the virus will infect the Boot Manager
  342. partition.  The next time you use Boot Manager, it will overlay part
  343. of the virus, and the next time you try to boot from the hard disk,
  344. the system will probably hang.  I don't know how good DOS anti-virus
  345. programs are at detecting and repairing Boot Manager partitions in
  346. these cases; IBM AntiVirus can do it.)
  347.  
  348. - - -- -
  349. David M. Chess                   \
  350. High Integrity Computing Lab     \    The devil finds work for idle MIPS.
  351. IBM Watson Research              \
  352.  
  353. ------------------------------
  354.  
  355. Date:    Wed, 25 Nov 92 09:15:26 -0700
  356. From:    martin@cs.ualberta.ca (Tim Martin; FSO; Soil Sciences)
  357. Subject: Re: FDISK /MBR and FORM Virus (PC)
  358.  
  359.  
  360.  
  361. gscobie@castle.edinburgh.ac.uk (G J Scobie) writes:
  362.  
  363. >Thanks for all the info regarding FDISK /MBR.  However, I attempted to
  364. >disinfect a PS/2 Model 55 with the FORM virus using a coldboot from my
  365. >DOS 5.0 disk created for such a purpose, ran FDISK /MBR and then ran
  366. >F-PROT 2.05 and it still reported FORM as being present in the boot
  367. >sector.  Using SYS.COM, then running F-PROT again showed the disk to
  368. >be clean.  Unfortunately I don't have the kit - or indeed the time -
  369. >to sit down and experiment as the machine had to be cleaned up as
  370. >quickly as possible.  Is this a case of 'ghosting' with a scan string
  371. >still left on the disk though the virus is inactive?
  372.  
  373.  
  374. The FORM virus is not like stoned and Michelangelo and the others,
  375. in that it does not infect the main boot record, where the partition
  376. table is.  It infects the DOS boot sector; the boot sector of the
  377. DOS partition.  So FDISK /MBR, which rebuilds your main boot record,
  378. doesn't touch the FORM virus.  SYS.COM, though, rewrites the DOS
  379. boot sector, as I recall, so it would probably remove the FORM virus,
  380. but would not clean viruses like stoned and Michelangelo from a
  381. hard disk.
  382.  
  383. It isn't a case of ghosting, no.
  384.  
  385. Sorry, I can't really help on the other questions you had.
  386.  
  387. Tim.
  388.  
  389.  -------------------------------------------------------------
  390.   Tim Martin                   *
  391.   Spatial Information Systems  *   These opinions are my own:
  392.   University of Alberta        *      My employer has none!
  393.   martin@cs.ualberta.ca        *
  394.  -------------------------------------------------------------
  395.  
  396. ------------------------------
  397.  
  398. Date:    Wed, 25 Nov 92 18:52:52 +0000
  399. From:    rslade@sfu.ca (Robert Slade)
  400. Subject: Re: Click, Click, Click when I typed help format (PC)
  401.  
  402. danielh@hadar.fai.com (Danial Ho) writes:
  403. >I experienced some weird behavior on my PC.  When I typed "help
  404. >format" or "format /?" on DOS 5.0, the screen will display
  405. >
  406. >CLICK:
  407.  
  408. Question: do you have a Dexxa mouse?
  409.  
  410. The Dexxa (and, I presume, other similar models) ships with a program
  411. called "CLICK.EXE" which is a part of the software used to enable
  412. mouse activity with programs that are not "rodent aware".  The CLICK
  413. program usually searches for a corresponding "menu" each time a
  414. program starts up.  The fact that it runs three times would seem to
  415. indicate that three programs are being invoked by your command.
  416.  
  417. =============
  418. Vancouver      ROBERTS@decus.ca         | Life is
  419. Institute for  Robert_Slade@sfu.ca      | unpredictable:
  420. Research into  rslade@cue.bc.ca         | eat dessert
  421. User           p1@CyberStore.ca         | first.
  422. Security       Canada V7K 2G6           |
  423.  
  424. ------------------------------
  425.  
  426. Date:    Wed, 25 Nov 92 13:55:54 +0100
  427. From:    Lars J|dal <protonen@daimi.aau.dk>
  428. Subject: Re: Atari ST Viruses! & Questions on the "Batman" virus (Atari ST)
  429.  
  430. AMN@vms.brighton.ac.uk (Anthony Naggs) writes:
  431.  
  432. >Trantor The Last Stormtrooper, <S12609@prime-a.plymouth.ac.uk> asks:
  433. [...]
  434. >> There is a virus on the ST called the "Batman" virus which according
  435. >> to ST Format (UK computer mag) does not have an executable bootsector
  436. >> yet the virus still manages to enter the system at boot up!
  437. >>
  438. >> How does the "Batman" virus boot without an executable bootsector?
  439.  
  440. >Perhaps it loads as an accessory, by modifying the start up script (sorry,
  441. >I can't remember what it is called - equivalent to AUTOEXEC.BAT for MS-DOS).
  442.  
  443. I don't think this is the case. According to the documentation in the
  444. German anti-virus program Virendetektor (which can be ftp'ed from
  445. atari.archive.umich.edu) this virus uses an undocumented feature of
  446. TOS to run.  Don't ask me for details - I know nothing of this myself,
  447. I'm just trying to give some useful information. And even if you could
  448. find somebody who knows how it works (like an anti-virus researcher) I
  449. guess that person would not like to tell anybody how.
  450.  
  451. >Hope you like this demonstration of my ignorance,
  452. >Anthony Naggs
  453. >Software/Electronics Engineer                   P O Box 1080, Peacehaven
  454. >(and virus researcher)                          East Sussex  BN10 8PZ
  455. >Phone: +44 273 589701                           Great Britain
  456. >Email: (c/o Univ of Brighton) amn@vms.brighton.ac.uk  or  xa329@city.ac.uk
  457.  
  458. And now I have added a demonstration of mine.
  459. +--------------------------------------------------------------------------+
  460. | Lars J|dal                  | Q: What's the difference between a quantum |
  461. | email: protonen@daimi.aau.dk|    mechanic and an auto mechanic?          |
  462. |                             | A: A quantum mechanic can get his car into |
  463. | University of Aarhus        |    the garage without opening the door.    |
  464. | Denmark                     |                    -- David Kra            |
  465. +--------------------------------------------------------------------------+
  466.  
  467. ------------------------------
  468.  
  469. Date:    Tue, 24 Nov 92 19:24:01 -0500
  470. From:    mechalas@mentor.cc.purdue.edu (John Mechalas)
  471. Subject: Re: Mr. Slade's listings
  472.  
  473. fc@turing.duq.edu (Fred Cohen) writes:
  474. >I am constantly amazed that ASP has not yet made Mr. Slade's lists.
  475. >We have been in the antivirus business since 1986, and yet the list
  476. >has hundreds of products/services/research groups/BBSs/etc. that have
  477. >been in existence for far less time, and with a very broad range of
  478. >different expertise.  I simply cannot believe that Mr. Slade is not
  479. >aware of the existence of ASP.
  480. >
  481. >  And then we have the hundreds of bug reports and fixes posted
  482. >about various products on Virus-L.  Why is this?  Don't these companies
  483. >deal with their customers over the phone?  Or is it just PR to keep
  484. >their names in front of the Virus-L public all the time?
  485. >
  486. >  I wish Virus-L's moderator would make a defined policy about
  487. >what goes on V-L and stick to it.  I could use the daily plug for my
  488. >products and services too, and yet we don't see all that much PR from
  489. >many of the companies that have products, only a small number that seem
  490. >to be in the Virus-L elite.
  491.  
  492. Those products also happen to be the most popular and most
  493. widely-used.  I think infomration about SCAN, FPROT, CPAV, Nortan AV,
  494. Solomon, and so forth is extremely important when they seem to make up
  495. the vast majority of anti-virus products installed on home and
  496. business PC's.
  497.  
  498. >  By the way, Today, ASP created over 1500 new viruses (using our
  499. >automated program evolution system), and NONE of the scanners listed as
  500. >the best around detected ANY OF THEM!  That means that the current
  501. >detection rate of the best scanners in the world is only 50\%, and in
  502. >another few days, we could knock their detection rates down to under 10\%
  503. >without much effort!  When will we start to see analysis based on the
  504. >likelihood of getting a virus not detected by a particular scanner?
  505.  
  506.    New viruses?  Meaning brand-new viruses?  What does this prove?  We
  507. already know that a scanner is no good at detecting a virus if it
  508. doesn't have a signature for it.  And hueristics is still
  509. experimental.  A couple of the hueristical scanning platforms even
  510. flat-out tell you that they are expeimental and shouldn't be relied
  511. upon as a sole means of defense.
  512.  
  513. >  Example:  (taken from Jon David's original example several years
  514. >ago - with modifications)
  515. >
  516. >  Virus 123 represents 0.12\% of reported incidents
  517. >  Product X detects Virus 123
  518. >  => Product X gets 0.12\%age point toward a 100\% rating
  519. >     of REAL WORLD EFFICACY!
  520. >
  521. >  If you want a second (and far less important) rating scale, you
  522. >might include a rating of detection against the CARO list (or some such
  523. >other thing) with weightings associated with the age of a virus in the
  524. >CARO list.  Hence you get worse ratings for not detecting older viruses
  525. >which are more likely to have spread further.
  526. >
  527. >  And then we have the problem of fair evaluations.  I don't see
  528. >how it is unfair to report any evaluation as long as you provide the
  529. >details about the testing methods used to determine the results and let
  530. >others respond to them.  Perhaps V-L should ONLY publish ratings under
  531. >the proviso that the details of the tests are provided with them!
  532.  
  533. I agree...though so far I haven't seen anyone post test results
  534. without also posting the test details as well.  One good example would
  535. be the recent MtE tests.
  536.  
  537. >  Well, that's my view of it all.  I figure I'll get plenty of
  538. >grief for having posted it (if it indeed gets posted), so don't bother to
  539. >complain directly to me - this is the sort of discussion we should have
  540. >on Virus-L in front of the whole world.
  541.  
  542. I'd say you'd get more grief for your tone, rather than your content.
  543.  
  544. - --
  545. John Mechalas                      | If you think my opinions are Purdue's, then
  546. mechalas@mentor.cc.purdue.edu      |      you vastly overestimate my importance.
  547. Purdue University Computing Center |             Help put a ban on censorship :)
  548. General Consulting                 |                       #include disclaimer.h
  549.  
  550. ------------------------------
  551.  
  552. Date:    Tue, 24 Nov 92 20:03:19 -0500
  553. From:    tyetiser@umbc5.umbc.edu (Mr. Tarkan Yetiser)
  554. Subject: Evaluations of AV products (was: Mr. Slade's listings)
  555.  
  556.    Hello everyone,
  557.  
  558. fc@turing.duq.edu (Fred Cohen) writes:
  559. >        And then we have the hundreds of bug reports and fixes posted
  560. >about various products on Virus-L.  Why is this?  Don't these companies
  561. >deal with their customers over the phone?  Or is it just PR to keep
  562. >their names in front of the Virus-L public all the time?
  563.  
  564.    I second that. Virus-L is turning into nothing more than a support
  565. BBS for a few products. It is sad.
  566.  
  567. >        I wish Virus-L's moderator would make a defined policy about
  568. >what goes on V-L and stick to it.  I could use the daily plug for my
  569.  
  570.    Maybe Santa will grant your wish this season :-) I doubt Ken will
  571. :-))
  572.  
  573. >        By the way, Today, ASP created over 1500 new viruses (using our
  574. >automated program evolution system), and NONE of the scanners listed as
  575. >the best around detected ANY OF THEM!  That means that the current
  576.  
  577.    Tell us more about this "evolution system". Do these cretures have the
  578. capability to spread? They must, otherwise they would not be viruses...
  579.  
  580. >without much effort!  When will we start to see analysis based on the
  581. >likelihood of getting a virus not detected by a particular scanner?
  582.  
  583.    I don't see much use for this analysis yet. The likelihood of average
  584. user getting a virus is increasing; however, I would wager that the virus
  585. that he might get is probably one of the common ones. And the popular
  586. scanners pick them off easily.
  587.  
  588. >        If you want a second (and far less important) rating scale, you
  589. >might include a rating of detection against the CARO list (or some such
  590. >other thing) with weightings associated with the age of a virus in the
  591. >CARO list.  Hence you get worse ratings for not detecting older viruses
  592. >which are more likely to have spread further.
  593.  
  594.    I don't agree that you can simply associate a weight based on the age of
  595. a particular virus. Your assumption about a virus being able to spread far
  596. since it is old is too strong. I think statistics based on actual infection
  597. reports should serve as a basis for assigning weightings of this sort.
  598.  
  599. >        And then we have the problem of fair evaluations.  I don't see
  600. >how it is unfair to report any evaluation as long as you provide the
  601. >details about the testing methods used to determine the results and let
  602. >others respond to them.  Perhaps V-L should ONLY publish ratings under
  603. >the proviso that the details of the tests are provided with them!
  604.  
  605.    Amen, brother! Posting so-called "reviews" without presenting any
  606. appropriate criteria is useless. The comments simply have no context
  607. in such reviews. They usually end up being a user-interface
  608. evaluation. What a joke! Some of the "reviewers" do not even conduct
  609. "live" tests. They are doing zoo testing even when evaluating
  610. integrity-based products. I think this is only an indication of the
  611. lack of understanding or technical ignorance on the reviewer's part.
  612. No wonder McAfee pays for some reviews. :-)
  613.  
  614.    Padgett has been crying out loud for an independent testing
  615. facility for a long time. Maybe he has been right all along; we do
  616. need such a service to conduct proper evaluations and tell the whole
  617. story.
  618.  
  619. Regards,
  620. Tarkan Yetiser
  621. VDS Advanced Research Group
  622. P.O. Box 9393
  623. Baltimore, MD 21228, U.S.A.
  624. tyetiser@umbc5.umbc.edu
  625.  
  626. ------------------------------
  627.  
  628. Date:    25 Nov 92 03:27:46 +0000
  629. From:    tck@bend.ucsd.edu (Kevin Marcus)
  630. Subject: Re: What is this "AV BBS list" nonsense? (general)
  631.  
  632. Well, you can remove my BBS from the list; "The Programmer's
  633. Paradise", which was in 619 - I took it down when I went to school.
  634. You can replace it with "The Raging Main", at 619-281-0855. (v.32bis)
  635.  
  636. ------------------------------
  637.  
  638. Date:    Wed, 25 Nov 92 15:14:50 +0700
  639. From:    frisk@complex.is (Fridrik Skulason)
  640. Subject: Re: Mr. Slade's Listings
  641.  
  642. fc@turing.duq.edu (Fred Cohen) writes:
  643.  
  644. >  By the way, Today, ASP created over 1500 new viruses (using our
  645. >automated program evolution system), and NONE of the scanners listed as
  646. >the best around detected ANY OF THEM!
  647.  
  648. So what ?  Scanners (by definition) are not guaranteed to detect totally new
  649. viruses.  Even a producer of scanners such as myself admits that. Detection
  650. of totally new viruses is a job for other types of programs - such as your
  651. own integrity software.
  652.  
  653. I know you realize that the different types of anti-virus software all have
  654. their uses - after all, you asked me once about bundling F-PROT with your
  655. package. However, as I I do not wish to be associated with a virus writing
  656. company, I am not interested in such a deal.
  657.  
  658. I don't approve of virus writing, virus writing competitions or anything which
  659. indicates that there is a positive side to computer viruses, and my personal
  660. opinion is that you might just have managed to kill your chances of being
  661. accepted as a CARO member.
  662.  
  663. - -frisk
  664.  
  665. ------------------------------
  666.  
  667. Date:    Wed, 25 Nov 92 13:03:02 -0500
  668. From:    "David M. Chess" <chess@watson.ibm.com>
  669. Subject: re: CHRISTMA Data (CVP)
  670.  
  671. I don't think your credibility is in shreds at all, Robert.  What a
  672. modest feller!  *8) I just noted one small thing that I thought might
  673. not be right.  The fact that VNET wasn't shut down is just a minor
  674. error in your excellant series; don't lose any sleep over it!
  675.  
  676. > Bridget, for example, states that CHRISTMA did not clean itself up.
  677. > She must know, since she had to clean up the remaining files.
  678.  
  679. Hm, interesting.  I just dug out my (carefully controlled) sample of
  680. CHRISTMA.  The last line is "ERASE CHRISTMAS EXEC".  So if run from
  681. the A disk, in an environment that doesn't mind extra letters in
  682. filenames, it will erase itself when it's done, I think.  It's
  683. possible that Bridget was dealing with a different version of the
  684. program?  Or that her users were interrupting it before it had a
  685. chance to finish (relatively easy to do in CMS).  But I think you're
  686. basically right on that one...
  687.  
  688. - - -- -
  689. David M. Chess                              50,000 lemmings
  690. High Integrity Computing Lab                   can't be wrong!
  691. IBM Watson Research
  692.  
  693. ------------------------------
  694.  
  695. Date:    Wed, 25 Nov 92 18:09:00 +0000
  696. From:    rslade@sfu.ca (Robert Slade)
  697. Subject: Re: Mr. Slade's listings
  698.  
  699. fc@turing.duq.edu (Fred Cohen) writes:
  700. >I am constantly amazed that ASP has not yet made Mr. Slade's lists.
  701. >We have been in the antivirus business since 1986, and yet the list
  702. >has hundreds of products/services/research groups/BBSs/etc. that have
  703. >been in existence for far less time, and with a very broad range of
  704. >different expertise.  I simply cannot believe that Mr. Slade is not
  705. >aware of the existence of ASP.
  706.  
  707. Ah, but Mr. Slade *is* aware of ASP!  If you will check the
  708. CONTACTS.LST file, you will see it listed at PO Box 81720, Pittsburgh,
  709. which address was obtained from Dr. Fred Cohen.
  710.  
  711. The reason that the antiviral produced by ASP has never been reviewed,
  712. is simply that, even after email to Dr. Fred Cohen, and letters to ASP
  713. at that address, nothing has been received (other than the above
  714. address).  This makes evaluation a tad difficult.  :-)
  715.  
  716. However, rest assured that, should it arrive, it would be given
  717. priority treatment.
  718.  
  719. ==============
  720. Vancouver      ROBERTS@decus.ca         | "Don't buy a
  721. Institute for  Robert_Slade@sfu.ca      |     computer."
  722. Research into  rslade@cue.bc.ca         | Jeff Richards'
  723. User           p1@CyberStore.ca         | First Law of
  724. Security       Canada V7K 2G6           | Data Security
  725.  
  726. ------------------------------
  727.  
  728. End of VIRUS-L Digest [Volume 5 Issue 190]
  729. ******************************************
  730.  
  731.  
  732.